feat: emit and seed the evo snapshot section in dumptxoutset and snapshot load - #7601

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/evo/snapshot_chain.cpp`:
- [BLOCKING] src/evo/snapshot_chain.cpp:469-470: Seed the credit-pool expiry history needed after the base
  Seeding only the base CCreditPool does not support cold snapshot continuation. On a mature v20-active chain, connecting base+2 calls GetCreditPool(base+1), whose ConstructCreditPool() reads the block at base+1-CreditPoolPeriodBlocks() to determine the amount leaving the withdrawal window. If background validation has not supplied that pre-base block, GetCreditDataFromBlock() throws `failed-getcbforblock-read`, and special-transaction processing converts the failure into a consensus rejection of the valid post-base block. The historical read occurs even when there were no withdrawals. Carry and seed the per-height expiry data, or obtain the required historical blocks before allowing continuation; the aggregate latelyUnlocked value cannot determine future expirations.
- [BLOCKING] src/evo/snapshot_chain.cpp:137-145: Include work-block state for quorums not yet mined at the base
  The builder registers work blocks only for mined commitments and carried historical rotation snapshots. For a v20-active base at H+5, where H is a DKG cycle boundary and the current mining window has not started, no commitment registers H-WORK_DIFF_DEPTH. The rotation horizons start at H-C, so they do not supply this work block either. A cold consumer validating the first post-base commitment for H requests that pre-base MN list through GetAllQuorumMembers(), but neither a seeded list nor its ordinary diff chain exists; GetListForBlockInternal() throws instead of allowing the valid chain to advance. Include the pre-base work lists and modifiers required by upcoming quorum processing, even before commitments are mined, and update ValidateEvoSnapshotAgainstChain() so its required-work set accepts and requires that state.

In `src/validation.cpp`:
- [BLOCKING] src/validation.cpp:3207-3211: Allow snapshot mismatches to reach the chainstate exception boundary
  This catch cannot handle mismatches raised through special-transaction processing because intervening handlers consume them. GetAllQuorumMembers() rethrows SnapshotStateMismatchError while the EvoDB transaction is active, but CheckSpecialTxInner() and ProcessSpecialTxsInBlock() both catch std::exception and translate it into consensus-invalid state (`failed-check-special-tx` or `failed-procspectxsinblock`). ConnectTip() then calls InvalidBlockFound() rather than rejecting the snapshot through HandleSnapshotStateMismatch(). Add explicit passthrough handling for SnapshotStateMismatchError in the intervening catch layers so the transaction unwinds before this boundary handles the local-state failure.

In `src/llmq/utils.cpp`:
- [BLOCKING] src/llmq/utils.cpp:340-341: Use the seeded modifier when constructing rotation snapshots
  Passing nullptr bypasses the seeded modifier when writing a reconstructed rotation snapshot. BuildNewQuorumQuarterMembers() receives the snapshot-aware modifier, but BuildQuorumSnapshot() recalculates its ordering here without the snapshot manager. When the historical work block is unavailable and its coinbase contained a non-null ChainLock, GetNonNullCoinbaseChainlock() returns no value, so this calculation uses the block-hash fallback instead of the seeded ChainLock-derived modifier. The activeQuorumMembers bitmap is consequently indexed in a different order from the order used by GetQuorumQuarterMembersBySnapshot(). This can conflict with an existing seeded snapshot or persist incorrect membership state. Pass the already-resolved modifier into BuildQuorumSnapshot() rather than recalculating it.

In `src/evo/evodb.cpp`:
- [BLOCKING] src/evo/evodb.cpp:275-277: Remove rejected snapshot-derived state as well as lifecycle markers
  Snapshot activation commits seeded records into the shared EvoDB keyspace, but DiscardSnapshotMarkers() removes only lifecycle bookkeeping and the retained section. A rejected `llmq_M3` modifier remains readable through GetSeededQuorumModifier() after the default identity returns to NORMAL. Once ordinary validation encounters that work block, it can raise the same mismatch again, now without an active snapshot for HandleSnapshotStateMismatch() to invalidate. Seeded MN-list, rotation, and credit-pool records likewise remain available to normal readers, contradicting the recovery path's promise to restart without snapshot data. Track or isolate snapshot-owned records and remove their unvalidated state during rejection while preserving independently validated records; do not erase the retained section before performing the cleanup that needs it.

In `<commit:23d04e1ef3d>`:
- [SUGGESTION] <commit:23d04e1ef3d>:1: Reword the commit body's end-to-end test claim
  The commit body states that `feature_assumeutxo_dash.py exercises the dump/load/complete cycle end to end`, but the script only calls dumptxoutset and checks returned metadata and the emitted marker. Its docstring explicitly says loading is added in M5. Reword the commit body to describe the emission checks actually present; the PR description repeats the same inaccurate coverage claim and should be corrected as well. This is a reporting correction, not a request to expand the test's scope.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `<commit:f728741f26e>`:
- [SUGGESTION] <commit:f728741f26e>:1: Reword the commit body's end-to-end test claim
  The current commit body says feature_assumeutxo_dash.py exercises dump/load/complete end to end, and the PR description additionally claims background-validation and recovery coverage. The test only mines quorums, calls dumptxoutset, and checks the returned metadata and DASHEVO marker; its docstring explicitly defers loading to M5. Update both descriptions to emission-only coverage so the recorded validation accurately describes what this test proves.

In `src/streams.h`:
- [SUGGESTION] src/streams.h:522-544: AutoFile::size helper is dead code despite bounding claim
  The added AutoFile::size() has no consumer in the snapshot load path or its templated codec. Decoding uses ReadBoundedCompactSize and SnapshotBoundedInput, so the PR description's claim that AutoFile::size() bounds decoding is inaccurate. Remove the unused cross-platform helper and correct the description, or wire it into an explicit remaining-byte bound if that is part of the intended implementation.

In `src/evo/snapshot_chain.cpp`:
- [BLOCKING] src/evo/snapshot_chain.cpp:137-145: Include work-block state for quorums not yet mined at the base
  (existing thread: https://github.com/dashpay/dash/pull/7601#discussion_r4052746670)
  Work-block state is collected from mined commitments and existing historical rotation snapshots, not from every cycle whose work block precedes the snapshot base. For example, a non-rotated quorum whose cycle has begun but whose commitment has not yet been mined contributes no work-block MN list or modifier. When that commitment arrives after activation, member verification needs the pre-base list and, after v20, potentially the work block's coinbase ChainLock. Neither can be reconstructed from headers and the base list alone. Rotation history also starts at the preceding cycle, leaving the current cycle dependent on emitted commitments. Include the bounded work-block dependencies needed by post-base commitments, including imminent cycles whose work blocks already precede the base, and validate that coverage independently of carried commitments.
- [BLOCKING] src/evo/snapshot_chain.cpp:469-470: Seed the credit-pool expiry history needed after the base
  (existing thread: https://github.com/dashpay/dash/pull/7601#discussion_r4052746662)
  Seeding only the base CCreditPool does not supply the sliding-window history needed to extend it. ConstructCreditPool(base+1) reads the block at base+1-CreditPoolPeriodBlocks() to subtract that block's unlocked amount from latelyUnlocked. On a cold snapshot load, that pre-base block need not be downloaded, and GetCreditDataFromBlock throws failed-getcbforblock-read when it cannot read it. The base aggregate cannot determine the individual amounts that expire over subsequent blocks. Carry and seed bounded per-block withdrawal history, or explicitly obtain the required old blocks before advancing the snapshot chainstate.

In `src/evo/evodb.cpp`:
- [BLOCKING] src/evo/evodb.cpp:275-277: Remove rejected snapshot-derived state as well as lifecycle markers
  (existing thread: https://github.com/dashpay/dash/pull/7601#discussion_r4052746668)
  The expanded cleanup removes the lifecycle markers but not the block-derived values seeded into the shared EvoDB. WriteDerived uses ordinary block-hash keys, and activation durably writes seeded MN lists, commitments, rotation state, modifiers, credit-pool state, and MNHF signals there. HandleSnapshotStateMismatch then discards the markers and promises to restart without snapshot data, while those values remain readable by normal-chain managers. A rejected value can therefore be reused or cause a subsequent WriteDerived mismatch instead of allowing independent recovery. Track and remove unvalidated snapshot-derived state on rejection, or isolate it until promotion, while preserving independently validated normal-chain data.

In `src/llmq/utils.cpp`:
- [BLOCKING] src/llmq/utils.cpp:340-341: Use the seeded modifier when constructing rotation snapshots
  (existing thread: https://github.com/dashpay/dash/pull/7601#discussion_r4052746667)
  BuildNewQuorumQuarterMembers selects members using the seeded-aware modifier, but its BuildQuorumSnapshot call sorts the active-member bitset using GetHashModifier(..., nullptr). When a pre-base work block is unavailable, the latter bypasses the seed and GetNonNullCoinbaseChainlock falls back to no signature, producing a block-hash modifier instead of the carried ChainLock-based modifier. The stored bitset is then indexed against a different ordering from the one used to reconstruct it, or disagrees with an existing seeded snapshot. Pass the already-selected modifier into snapshot construction, or thread the snapshot manager through this call.